\chapter{Implementation in OSGI}
\label{cha:4}

In the previous chapter we have built up a basic model for our agent. There we
defined the connections between the classes. That model has no implementation
yet. In this chapter we will map that model into different OSGi bundles
collaborate. This means that some bundles will work together and will be linked
with eachother through the classes, described in the previous chapter. 

Every section in this chapter will represent a bundle in OSGi. We will discuss
from each bundle the packages and the most important classes. There will be also
a lot of references to the source code. The code is deliverd on CD with this
thesis. In every section we will refer to a Bundle or Package(appendix
\ref{app:A}). In the text we only will talk about certain classes that are a
part of that bundle of package.

The reason to develop an agent in many different components, is that every
component has a different use. For example, we have made a web server component
that just puts different files on a server and are available for other agents
while another component will do all XML related actions.

Like mentioned earlier, a service in the OSGi framework is actually a single
object that is accessible by other components that depend on that service.
Different components will access the same object if they refer to the same service. 
Also some components will be publish services through an interface
other will directly publish their service and will be consumed in that way.

\section{General model in OSGi}

In Figure \ref{compdiag} the agent's model is described in OSGi components. This
picture is not a direct mapping of the classdiagram (Figure \ref{classdiagram})
and also contains components that were not described in the classdiagram. In the
figure also the dependencies (with cardinality) are given between all the
components or bundles. The connection of the Role with MyAgent works through an
interface because the agent must be able to handle more than one
role, like te cardinality describes. Also the socketcommunication runs through
an interface. This is not because of cardinality or multiple communication
possibilities. We needed an interface to implement an eventlistener for the
incoming messages.

The component MyAgent contains the classes Schedule, Commitment,
BasicBehaviour(and extensions) and MessageHandler. The reason why all those
classes are a part of that one component or bundle, is that is code that belongs
to the real agent and is not likely to be changed in the future.

Components like Server, SocketCommunication, XMLStreamService, RMI are
components that completely not relate to the class diagram in the previous
chapter.
The components are the OSGi bundles that help the agent communicate. These
communication bundles could be easily exchanged by other ones if we want to use
other protocols or datastructures. Thus these bundles are not a part of the
actual agent.

The MessageService component contains a service and the Message class of the
classdiagram. This is also done because if another kind of message would be
used, it will be easier to replace. 

The component Role is connected through the interface IRole. This is because the
bundle contains the class role that must implement the interface IRole like
described in previous chapter. The bundle also contains the classes Task and
TaskState. In practice the class Task must implement the interface ITask,
this will not be desclared as a service. 

%Regeneration of such single objects is also possible and then a service factory
% is needed.
%In that way every component will refer to his own service-object. 
%In this thesis we do not need the last setting because we only need one
% communication socket, web server etc.

\begin{figure}[b!]
  \centering
  \includegraphics[scale=0.65]{fig/compdiag}
   \caption{Component Diagram}
   \label{compdiag} 
\end{figure}

\section{Bundle : be.kul.osgi.ds.myagent}

From the design in the previous chapter we will integrate the classes like the
Agent, Schedule, Commitment, MessageHandler and the BasicBehaviour with
extended classes. Also extra and helper classes will be discussed here. The
bundle MyAgent contains 3 packages that define the working of the agents.
This bundle depends on all the other bundles described in this thesis, except
for the bundles that represent a role. These are optional dependencies since an
agent can own zero or more different role implementations.

\subsection{Package : be.kul.osgi.ds.myagent}

\subsubsection{MyAgent}

The class MyAgent is the main class and is connected to all the other bundles
and services that makes an agent complete. 

MyAgent contains also the name for the agent and that will be specified as a VM
argument. This makes it easier to make many different agents with all the same
components. 

Next to the name the class also consists of a Schedule, MessageHanlder
and a SyncThread. These classes will be handled further in the section. 

This class will also be connected to all the roles an agent can have. Through an
interface many roles can be connected to the agent and it is only accessible
through this class.

This class contains also a filesystem function. This function will be used to
temporarily store files and bundles that will be exchanged through the
webserver.

A listener for incoming messages is also implemented.
The agent will listen through another bundle (comminterface) on a socket to
imcoming messages. Every message will be handled by the messagehandler.


\subsubsection{SyncThread}

This is a thread that polls the situation of the simulation environment through
an RMI interface. This is how the agents and the environment will get
synchronized. This class will be discussed in more detail in the next chapter.

\subsubsection{BundleHandler}

This is a class that extends the MyAgent class with methods related to bundles.
Interesting functions are :

\begin{itemize}
  \item The Filesystem functions like described in the chapter of OSGi
  \item public String packBundle(String tempdir) : a function that packs the
  bundle in a zipfile to make it exchangeable.
  \item public ArrayList<Bundle> getDependencies() : This is the function that
  will search and return all the dependencies of a certain Role.
\end{itemize}


\subsubsection{Schedule}

This class is built up like described in the previous chapter. 
It contains a list of commitments and some functions to check if a new task or
commitment can fit in the current schedule. Also a functions for basic internal
rescheduling and sorting is implemented.

\subsubsection{Commitment}

Also the class Commitment is an implementation of the descriptinon in previous
chapter. The Commitment consists of a Task, TaskState, a starttime, and endtime.
The starttime and endtime are set only when the task fits and is added into the
schedule. For the task two fields are provided, in one the task can be added as
an XML-string, This is done because some tasks are added when the corresponding
role in not installed yet. The other field  is for a real task
object that implemented the ITask interface. When the corresponding role is
installed and active, the XML-string can be transformed to the real class. The
taskstate will be assigned is the task is shared when it was in execution by another agent. The
CurrentTaskState of that role will export that state and eventually will be
passed on together with the task in the commitment in another agent. Next to the
fields, the class also contains a method that transforms the task in XML to an
actual ITask object.

\subsubsection{ZipUsingJavaUtil}

The class ZupUsingJavaUtil\cite{website:zipfiles} is a class that offers the
capabilities to put certain folders and files in to a zipfile. This is mostly
used for the packaging a bundle or role to make them easily exchangeable. 


\subsection{package : be.kul.osgi.ds.myagent.Role}

\subsubsection{RoleHandler}

This class is the same as the BundleHandler but specifically for Bundles or
services that implement the IRole interface.

\subsubsection{TaskHandler}

This class is helper class for the MyAgent and contains function concerning the
tasks and classes that implement ITask. 


\begin{itemize}
  \item ContractNetInitiator shareTask(ITask t, IRole role) : This function will
  prepare a behaviour to exchange a task with the rest of the agents.
  \item public IRole getRoleFromTask(String xml) : If we get a task-object in
  the form of an XML, it will return the associated Role if the agent owns that
  role.
  \item public IRole getRoleFromTask(ITask t) : If we get a real task-object, it
  will return the associated Role if the agent owns that role.
\end{itemize}

\subsection{package : be.kul.osgi.ds.myagent.message}

This package contains all the classes to set up the social behaviour between the
different agents.

\subsubsection{BasicBehaviour}

This interface provides standard functions such that implementing classes are
all accessible in the same way. The functions are :

\begin{itemize}
  \item String getID() : returns the conversation id of the behaviour
  \item void HandleMessage(MessageObject mo) : handles the message in the
  behaviour
  \item public boolean isInterested(MessageObject mo) : check if the behaviour
  is interested in the message. 
  \item public void start() : Will start the behaviour.
\end{itemize}

\subsubsection{MessageHandler}

This class will handle all the incoming messages and creates new behaviours when
messages with a specific performative arrives. All the behaviours contain, like
every message, a conversation-ID. This is because every message is
associated with some behaviour and when a message is interesting for a
behaviour, the ID's must match. In table \ref{table-performative} we can see
which performative comes from the initial behaviour and which behaviour will
respond behaviour is started by that performative on the other side to respond.


\begin{center}
\begin{table}[h!b!p!]
    \begin{tabular}{ |l|l|l|}
    \hline
    Initiating Behaviour & Message's Performative  & Responding Behaviour\\
    \hline 
    ContractNetInitiator & CFP & ContractNetResponder \\ \hline
    AskCapability & ASKBUNDLE & GiveCapability \\ \hline
    AskRole & ASKROLE & GiveRole \\ \hline
    \end{tabular}
    \caption{incoming message's performative that invoke creation of a
    behaviour}
    \label{table-performative}
    \end{table}
\end{center}


\subsubsection{Other behaviours}

From the BasicBehaviour we will create some extensions. The agent will than
be able to communicate and collaborate with the rest of agents.

Here is a list of the extra behaviours : 

\begin{itemize}
  \item SellAllTasks : Just sets up ContractNetInitator behaviours for all the
  tasks that must be exchanged.
  \item ContractNetInitiator \& ContractNetResponder : These behaviours
  implement the ContractNet protocol for exchanging a task. The responder
  contains the flow for calculating the cost. The initiator eventually will
  chose the agent who provides the commitment with the best cost.
  \item AskRole \& GiveRole : They will yechanges a role when there is asked
  for.
  AskRole will send out a multicast message with the asked role. An agent who has the
  role, will pack it up, publish it for exchange and will send back a message
  with the URL of the file.
  \item AskCapability \& GiveCapaBility : This is the same as previous
  behaviours but for exchanging a capability.
  \item ReschedulingInitiator\& ReschedulingResponder : These behaviours will be
  started if external rescheduling is needed to complete all the tasks in the best time
  possible. Tasks will be switched if the the switching tasks will deliver a
  better solution.
\end{itemize}

All the behaviours are constructed with a Finite State Machine(FSM)
\cite{website:fsm}. This machine only responds to incoming messages. In the
messagehandler a first filtering is done by checking the conversation-ID. Then
in the behaviour will respond if it is interested in the message. This is done
by checking the state of the behaviour and the performative of the message. Each
state has its own performatives where it reacts upon.


\section{be.kul.osgi.ds.socketcommunication}


Incoming messages will be a simple string in the form of an XML. To be precise
it will be a serialized MessageObject from the MessagingService. Now we have to
find a way to transport these serialized objects from one agent to the other.

To get a connection between the agents we did not look at the performance or
reliability of a connection. This project needed to have on the one hand an easy
implementation where simple messages could be sent between agents on the same
computer or in a network. On the other hand it needed an easy implementation of
a multicast. Therefore we will use the
DatagramSocket\cite{website:udp-multicast} and is already
delivered by the Java packages. That socket also allows an easy implementation to send a multicast message such that multiple agents can be contacted at once.

Since the simulation runs all the agents on the same system,  the socket of
every agent must listen to the same port on the same address. This may cause
problems with some socket implementations. To listen for messages, a multicast
socket is the best option. That socket allows other multicat sockets listening
on the same port on the same network address or in the same system. But this
method will also work if every agent works with a different network address.

Continous waiting for incoming messages can block the working of the agent.
Making the multisocketserver threaded will solve that problem.

\section{be.kul.osgi.ds.comminterface}

When a socket for receiving messages is threaded we must add some
kind of custom event and a listener such that the agent can handle every
incoming message.

Since this modularized the agent's structure we have to make an event and
listener that bridges the gap between bundles. Therefore I present a separate
interface-bundle that contains a communication interface to align the service
for communication, a listener interface and an event-object that represents
vital information about a message that is received \cite{website:custom-event}.

\subsection{be.kul.osgi.ds.comminterface}

\subsubsection{MyEvent}

The event that will be dispatched contains the full message, and the port and
the address from where the message came from. Since in our demo all the agents
will operate on the same machine the last two fields are not used.

\subsubsection{CommunicationInterface}

The service that will actually implement the ways of communication will have
ti implement this class. This interface provides methods for initialization,
sending messages, adding and removing an eventlistener.

\subsubsection{MyEventListener}

This class is to add a listener to the implementing class. This will be in this
case the MyAgent class.


\section{Bundle : be.kul.osgi.ds.messageservice}

\subsection{Package : be.kul.osgi.ds.messageservice}

\subsubsection{MessageService}

To establish uniform communication between the agents some standards must be
followed. 

Therefore a messageservice bundle is developed. That bundle depends also on the XMLStreamService in order to 
easily serialize a message object into a XML string. The bundle only consists of a Simple component class that represents the service.
 The other and most important class is the MessageObject class. This class defines the whole structure of a message that would be sent between the agents. 

\subsubsection{MessageObject}

The basic structure of the message is taken from the standardized Agent
Communication Language (ACL) from FIPA\cite{website:fipa-acl}.
The actual source code came from the ACL implementation of
JADE\cite{website:jade}. That code is adapted in some ways.
Extra performatives were added to distinguish different messages more easily. 

Also an extra field 'receiver' was added in the class. This is a string that
represents the name of the receiving agent. Normally in ACL the 

In the simulation all the agents are executed on the same machine and thus all
have the same physical address.
The agents are all listening to the same port through the multicast socket. The
only thing to distinguish which message belongs to which agent is the agent name
defined in the messages.

In practice every message will be sent to the multicast address. 
And if the message is directed to all the agents in the environment the
destination string will be set as 'multi'.

Other changes in the source code of the JADE ACL implementation were removals of
code. Some of the code was not useful for this application and also conflicted
when compiling the code.

\section{be.kul.osgi.ds.rmi}

\subsection{bundle : be.kul.osgi.ds.rmi}

This is a bundle to connect the agent-middleware to the demo-environment. A
short description of the bundle will be given here but more detail will be given
in the paragraph concerning the demo implementation. The Demo environment RinSim
is the RMI server that contains 3 interfaces, every agent will also implement
those interfaces in the bundle :

\begin{itemize}
 \item Serverinterface : This interface is an interface to synchronize and initialize every agent with the demo environment. 
 Since every agent and the demo environment each run in a different virtual machine it is preferred to synchronize each agent with it's 'physical' state in the demo environment.
\item 	pickupinterface : This interface is meant to give the order to the physical entity of the agent to go pickup 
a package and deliver it at the depot. Parameters are here the package ID,
pickup location x and y, agent name.
\item 	dropoffinterface : This interface is gives the order to the physical
entity of the agent to go get a package at the depot and deliver it at the delivery location. Parameters
 are here the package ID, delivery location x and y, agent name.
\end{itemize}

The first idea was to integrate only the needed interface in to the Role-components. 
But integrating the multiple RMI-clients in such a way gave problems. All the interfaces must be accessed by the same object. 
For that reason I made a single RMI service component where all the interfaces are combined in one bundle. 

To simulate that the one Role only accesses code to execute a pickup, the code in Role1 only has a function that can access the pickupinterface. 
The other role can only access the dropoffinterface


\section{be.kul.osgi.ds.xmlstreamservice}
\subsection{package be.kul.osgi.ds.xmlstreamservice}


An easy and well-known form to represent data is XML. Since we have chosen to
use this type of structured data to communicate, we need some implementations to
handle this kind of data. Java as a programming language has attracted some
interesting developments where objects can be reformed to XML and vice versa.
This is a interesting feature we will also exploit in our application.

The components that consume this service are MyAgent, MessageService, and every
bundle representing a Role. The main purpose of this component is to serialize
objects created by those components and retrieving important information from XML-messages.

This component is developed for the XML-operations that we need. There are 3
different operations that are interesting for out purposes :

\begin{itemize}
\item Serialize an object to a XML-string, and de-serialize a xml-string back to an object
\item 	get a sub-XML string from an xml
\item 	get a value from an XML-tag 
\end{itemize}

Each of these operations is actually handled by a different implementation. For
(de)serializing objects from and to XML we used an implementation of a 3rd party
provider called XStream\cite{website:xstream-tutorial}. To get a sub-XML string
we used the package javax.xml.xpath . For the last operation we used the package org.w3c.dom .

\subsubsection{Serializing and deserializing objects with XStream}

Xstream is a third party package that allows us to serialize an object to a
XML-String. Also the opposite is possible but with some restriction.
If we get a XML-string from an object or class that not yet exists in the
virtual machine the object cannot be created from that XML.
It is logical since it has no clue about that class or object. This is a very
important knowing because a Tasks is different for every type of Role and every
Role service component has its own Task. If we receive a Task from a Role
service component we do not have, we cannot handle the task because of the
reason above.

To use XStream in an OSGi bundle we have two issues to tackle. The first issue
is how to include the package of XStream itself in the application.
The other issue is a classloader problem that can occur when deserializing
objects.

To include the XStream package in to the application we can best rely on the
fact that a bundle can hide its internal working from the rest of the OSGi
environment. We will include the package of XStream in our XMLStreamService and
we will compile it with our bundle. In that way no other package will know about
using this package and everything will go through the service component.

The OSGi framework will provide a classloader for every bundle that is
installed in the execution environment. A classloader keeps track of all the
classes that a bundle or application contains. So when the bundle must deserialize a
XML string to an object and gets a class from another bundle it will fail.
Because that class is not known by the current classloader. The
implementation of XStream allow us to link the proper classloader to the
deserializing unit of XStream \cite{website:xstream-problem}. That resolves the
problem of unknown classes.

\subsubsection{SubXML with the package xpath}

When sending a task as content in a MessageObject, the serialized version will
result that the XML of the Task will be a subXML of the serialized
messageObject.
In practice I encapsulated the Task-object in another xml tag that could be
filtered out later. The implementation to do that extraction easily is the XPath
implementation \cite{website:subxml}. We will define some filter that we will
apply on the XML.

The function public String Sub(String xml, String value) makes use of the
XPathExpression to define a filter. The function will return the subXML in a string.
The given arguments are the input xml, and value represents the XML-tag we want to filter.


\subsubsection{XML value from XML-tag with the document object model}

Getting values from tags in a XML can also be useful. If the serialized object
cannot be reformed back to a real Java object, and if we know that the object
should have standard fields, reading those standard fields are a must.

With the Document Object Model(DOM) implementation in Java we can extract the
values from tags in the XML \cite{website:xmlvalue}.

The function public String getValue(String xml, String value) in the
XMLstreamservice component returns the value from the first tagname (<value>)
from the given XML xml. Node.getTextContent() is the function to realize this.

Since every Task must have some standard fields, those fields will always be included in the XML. 
So it is also easy to derive the due-time, estimated execution time etc from those tasks delivered in XML.

Since every agent has a schedule to plan aheadband every agent may have the
capability to insert a new Role, we must have some technique to schedule unknown
Tasks. We predefined some standard fields in a task such that there extractable
by the XMLstreamservice. Standard fields like the due-time for a task and the
estimated execution time, can already give us some information to plan in the
tasks.

When a task is send, and the sending agent was busy with that task, an extra
field is added in the message-content : currentTaskState. This is also dependent
for every role in our model. when planning such a task, it is added to the
Commitment as a string. When the Commitment is made ready for execution, the
currenttaskstate-string will be reformed in the appropriate object by the Role.

Tasks are transferred between agents in the form of an XML-string. The one agent
serializes the Task object to a xml String. The interesting thing of serializing
such objects to XML is that the root tag-name is the whole class name of the object.
Since we made a Task dependent of a Role we easily can derive the actual needed
Role from that XML. In the XMLStreamService we also made a general function to
derive and return the Role-name from that XML.

\section{be.kul.osgi.http.fileserver}

To exchange executable code in forms of OSGi bundles we have chosen for making a
small webserver that hosts our files. We chose this kind of server because of
the ease of development and configuration. Also an extra advantage is that
installing bundles in the framework can be done by just giving a URL(in string notation) to the function :
BundleContext.installBundle(String location)

The equinox implementation of OSGi already has some prebuilt web server bundles
provided. Making a new bundle with some specific configuration makes this a kind
of server that is built and deployed very fast.

In following steps we made a small server that hosts the files for exchange
\cite{website:osgi-webserver}.
\begin{enumerate}
 	\item Make new bundle (as a declarative service)
	\item Add a folder in that bundle that will contain the static files for
	exchange
	\item Add a plugin xml with extension point to
	org.eclipse.equinox.http.registry.resources
\end{enumerate}

With this extension point we can set our exchange folder and link it with an URL space

\subsection{Bundle : be.kul.osgi.http.fileserver}

After this procedure we get a server that not yet fits our needs. 
This server is static in the sense that the files we want to share must be already in the exchange-folder. 
Because of that shortcoming we added a service to the bundle such that files can be copied from different data spaces in bundles to 
the exchange folder in the web server.  

\subsubsection{Server}

This service only implements one method :

public String publish(String path, String filename) 

This function publishes a given file, with path + filename to the web server. This function returns on success the filename.

Like mentioned in the chapter of OSGi, we also implemented the activate function for implementation class. 
This we use for initializing the physical pathname for the exchange-folder since 
such pathnames can differ from implementations and virtual machine.

Only the MyAgent bundle implements this service since only the agent itself will regulate publishing of new files and bundles.

\subsubsection{VM parameter}

For demo and simulating purposes we still have to tackle an important issue. Such servers need a connection port and in our case we will run different agents, 
each with a server, on the same computer. In this case defining the same http port for every server will bring along conflicts. 
Therefore an easy configuration is needed to configure different ports for every
agent. The easiest configuration of those ports are at the virtual machine
arguments\cite{website:jetty-port}.
The jetty-server components that we use have implemented such configuration in VM arguments : 
-Dorg.eclipse.equinox.http.jetty.http.port=8080

With these arguments http servers can be integrated more flexible in systems
where more than one agent is running or where other applications with some ports occupied are running.



\section{Bundle : be.kul.osgi.ds.IRole}

This bundle is actually a transparent bundle. It contains only two interfaces,
that are exported and thus visible for other bundles who wants to use them.
In practice this bundle will function as a connector for all the bundles who
implement one of the interfaces into its service component. The relevant use for
this bundle for agents is that one can handle many different roles that
implement the IRole interface. To let a service component act as a IRole, it
must be declared that provided service is from the Interface IRole.

This bundle is not made as a declarative service since it does not provide a
service itself and does not have any dependencies.

\subsection{Package : be.kul.osgi.IRole}

\subsubsection{IRole}

Executing a task is an agent's Role main goal. So it is necessary that such a
function is declared in the interface. Also making a task from some basic
information or a XML-string containing a specific task is necessary. To make
also state migrations it could be interesting adding a function that returns the
state of a specific task. To make that as basic as possible that will be a
string in the form of a XML, specified by an implementing Role.

Execution of a Task :

\begin{itemize}
 \item public void execution(ITask t, String agent) : This function will execute a task that does not contain a currenttaskstate. The agent name will also be given to the function because the role must access the server of the Demo-environment and must know which agent will execute that task.
 \item public void execution(ITask t, String agent, String CurrentTaskState) : This function will execute a task That contains a currenttaskstate.
\end{itemize}

Making a task:

\begin{itemize}
 \item public ITask makeTask(String xml) : This function will make a task from a
 given XML. It will only produce a correct object if the XML represents a Object
 created by that implementation. A XML from another implementation will give
 produce a wrong object or an error.
 \item public ITask makeTask(String ID, long duration, long due, double x,
 double y) : This function is only important to initialize some task. At the
 start of a demo, some tasks must be already been added to the agents. Because
 of our client-server demo environment this function helps us to easily add the
 tasks at initialization.

 \end{itemize}

Produce the current state of a Task :

\begin{itemize}
 \item public String getCurrentTaskState(String agent) : When an implementation
 of the IRole interface is busy with a task it is possible that the task will be
 shared. When executing that task will have some other state.  This function can
 be called and it will return a current state of the Task.
\end{itemize}

\subsubsection{ITask}

As explained in the model/architecture of the agents. Tasks will only contain
the parameters so that a Role can correctly execute the tasks. But there must be
some basic field in a Task such that basic scheduling can be done for tasks that
are unknown for the agent and where still some capabilities or a role must be
downloaded.

\begin{itemize}
 \item public long getDue() : get the Due-date/time for a Task
 \item public long getTime() : get the estimated execution time for a Task
 \item public String getID() : get the ID from a Task
 \item public boolean isDone() : Returns if the Task is done or not.

\end{itemize}


All the roles must have the same structure in order to be good
interchangeable between agents. The interface IRole from the bundle with the
same name must be implemented in the service component. It is advised that the
class name for the service component is called 'Role' while the name of the
bundle can take any name. Also a Task class must be included and must implement
the ITask interface. This is for the easy of putting a Task from any kind of
Role-bundle in the Commitment or Schedule. Every Bundle that defines a Role for
an agent must have some Standards to be accepted by an agent. The bundle must
consist of a class Role and a class Task. The Role class must implement the
IRole interface and the Task must implement the ITask interface. This Bundle
must also be implemented as a Declarative Service in OSGi. The
class Role must act as the service component and also deliver the service IRole with that component. The actual different Roles will be handeled in more detail in the
next chapter since it leans more to the demo implementation.


\section{Bundle : be.kul.osgi.ds.capability1}

This bundle is developed to test the need of sharing capabilities/resources
between the agents. The bundle represents the component Capability in figure
\ref{compdiag}.

\subsection{Package : be.kul.osgi.ds.capability1}

\subsubsection{Capa}

This bundle act as a service that couples Role1 with the
RMI-component. The code that this service contains is all the RMI's interface
functions to make everything from the RMI-component available for Role1. In the
next chapter this bundle will be explained in more detail.

